home *** CD-ROM | disk | FTP | other *** search
The following are release notes for version 4.04 domestic Jumbo Colorado Backup for DOS release. Below is a list of parts affected by this release: 88-0147-404 SFTWR,JUM,5H,DOS,ENGL,DIST 88-0148-404 SFTWR,JUM,3L,DOS,ENGL,DIST 88-0206-001 SFTWR,JUM,3H,WDOS,ENGL,DIST ** This is the combo disk for CBD and CBW. This release includes the following enhancements over 4.03: 1. The minimum memory requried to run tape/diagnostics has dropped to 400K. 420K is still the published minimum in the User's Guide. 1. Colorado 700 (or 500 or Jumbo 500 or Buzzard, whichever name is being used now) is supported. 2. Diagnostics for Jumbo is now available. This functionality is supported as a command line option (TAPE DIAGNOSE). Originally this software was a stand alone tool, but to save space on the distribution disk it was integrated into the tape software. The important thing to note is that, although the tape software and diagnostics have been integrated, you cannot access the diagnostic functionallity from the tape menuing software. Likewise, you cannot access the tape software from the diagnostic menus. An addendum to the Colorado Backup for DOS User's Guide will ship with the product until this documentation can be integrated into the manual. Please refer to the addendum or user's guide for details on the operation of the diagnostic software. The rest of this section contains some special hints and trouble shooting ideas. Base Address Test: The purpose of the base address test is to verify that the selected base address does not conflict with other I/O cards in the system. This test applies only to CMS controller cards, since the base address for native floppy controllers is fixed at 03F0H. The tape controller uses sixteen consecutive addresses starting at the base address. If the address range used by another card overlaps the tape controllers address range, a base address conflict exists. The base address test performs a series of reads and writes to the address range. The tape controller will respond in a unique manner to the read/write sequence, thus allowing us to recognize that it can be accessed at that address range. With this type of intrusive testing, it is possible to cause the system to hang. This is not a bug in the diagnostics software. The problem is that there is no way of knowing how some I/O cards will respond to read/write sequences to their registers. For example, the NE-2000 network card will hang the system if a read is done at the last byte in the address range. Since the base addresses are tested in ascending order, the user may never get past a base address that hangs the computer. To resolve this, the base address test keeps track of which base addresses have caused the system to crash. The list is maintained transparently in TAPE.CFG. In the Confidence Test, the base address test will automatically skip any addresses which hang the system. If the user selects I/O Conflict Test from Advanced Options, they will be warned that previous attempts to test a base address caused the system to hang, but they will have the option to override the warning. With this arrangement, the user only has to experience, at most, one crash per bad I/O address. Keep in mind that for the majority of I/O cards, the base address test is benign. IRQ Conflict Detection Test: The purpose of the IRQ Conflict Detection Test is to determine whether a specific IRQ can be used by the tape controller card. Similar to the base address test, this test applies only to our cards. The IRQ test will configure the tape controller card for a specific IRQ and then attempts to generate 100 consecutive interrupts. For each interrupt, the interrupt latency is measured. If all 100 interrupts are received and the maximum latency is less than 500 uS, the interrupt passed the test. The test results indicate two levels of non-conflicting IRQ's ("Passed" and "Recommended"). If the interrupt was masked prior to the test, the IRQ is "Recommended". If the interrupt was unmasked, the IRQ "Passed". In both cases, no conflict was detected; however, the fact that the IRQ was unmasked seems to indicate that someone or something made use of the IRQ since the system was booted (all IRQ's are masked by default at system boot time). When selecting an IRQ, the "Recommended" IRQ's are obviously preferred. But if none exist, select one from among those that "Passed". The order of preference is subject to debate, but my experience leads me to suggest the following: Order of preferrence for IRQ selection: IRQ6 IRQ5 IRQ7 IRQ2 IRQ3 IRQ4 IRQ10 (TC-15 only) IRQ11 (TC-15 only) The reason that the IRQ test prompt the user to reboot after the test is complete is because the IRQ test may cause drivers and I/O cards to become disabled due to starvation. For example, many network cards "ping" the server on a regular interval. When the IRQ used by the network card is tested, the connection to the server is lost. Having the user reboot allows any side effects caused by the IRQ test to be corrected. Most of the time, you can side-step the reboot if you can live with the side effects (if any). Communication Test: The communication test verifies that communication can be established between the system and the tape drive. The test progresses incrementally, testing communication between each functional component in the communication path. System to controller chip (via system bus) Controller to firmware (via data cable) Firmware to drive electronics (via firmware commands) The communication executes the following steps: 1) Reset the floppy controller chip 2) Attempt a drive reset 3) Verify the data cable physical connections 4) Verify the data cable via blind communication 5) Test ability of drive to send/receive bytes by querying for the drive status and firmware version. Because most of the lines in the data cable are not tied to accessible controller chip registers, it is not possible to individually verify each line. The lines which can be verified are INDEX, WP, TRK0 and STEP. Since the WP and TRK0 lines are tied to registers in the controller chip, they can be verified physically as well as functionally. If the data cable is connected upside-down, the test can detect it because the WP line will be grounded. If the data cable is offset by a row (vertically misaligned), the TRK0 line will be grounded. When the test is first started, it is important that there is not a tape cartridge inserted into the drive. When the drive reset is issued, the drive assumes a power-on state. If there is a tape in the drive, the autoload will proceed, which will conflict with the blind communication and cause commands sent to the drive (during autoload) to be ignored. During functional verification of the data cable, the user is prompted to insert and then remove a write protected tape cartridge. This has the effect of "wiggling" the WP and TRK0 lines. The firmware commands issued (via STEP pulses) to sense the drive status causes transitions to occur on the STEP and INDEX lines, allowing verification of those lines as well. In addition, the write protect sense switch is verified and reconciled against the state of the WP line. Throughout the test, interrupts are generated by the floppy controller. These interrupts are counted and any missed (or superfluous) interrupts are reported. Read/Write Test: The read/write test verifies the ability of the tape drive to write and then read a large block of data. The block consists of greater than 1 but less than 2 tracks of randomly generated data. The actual number of segments written depends on the capacity of the tape. The block size is set so that regardless of where on the tape the data is written, the drive will read/write in both directions. The random data pattern is repeated for each 32K segment. The 3K ECC (error correction code) is not computed, applied or used. The raw data is written and read without error correction. Errors encountered during the read phase are reported in the following manner: Bad Sectors = Number of sectors with 1 or more bad bytes Bad Segments = Number of segments with 1 or more bad sectors The Read/Write test will write to and read from an unused section of the users tape. The test will not destroy or affect any good volumes stored on the tape. The test requires up to 5700 Kbytes (depending on the type of drive) of available space on the tape. The space is used temporarily (only for the duration of the test). Due to the way that tape volumes are maintained on the tape, it is possible to have a tape that reports > 5700 Kbytes free (by View Tape Status) but is reported by the Read/Write test to be full (less than 5700 Kbytes free). Here's an example of how this can happen: A) Consider a tape that contains 4 volumes as illustrated in the diagram below. Tape Status would report that the tape has 3 Mb available. ƒ¬ƒƒƒƒ¬ƒƒƒƒ¬ƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒ¬ƒƒƒƒƒƒƒƒƒƒƒ¬ƒƒƒƒƒƒƒƒƒƒƒƒƒø ≥ ≥ ≥ ≥ ≥ ≥ ≥Vol ≥Vol ≥ Vol (100 Mb) ≥ Vol (2 Mb)≥ free (3 Mb) ≥ ƒ¡ƒƒƒƒ¡ƒƒƒƒ¡ƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒ¡ƒƒƒƒƒƒƒƒƒƒƒ¡ƒƒƒƒƒƒƒƒƒƒƒƒƒŸ B) The user then performs a quick erase on the last two volumes. The tape now has 105 Mb free. ƒ¬ƒƒƒƒ¬ƒƒƒƒ¬ƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒ¬ƒƒƒƒƒƒƒƒƒƒƒ¬ƒƒƒƒƒƒƒƒƒƒƒƒƒø ≥ ≥ ≥ ≥ ≥ ≥ ≥Vol ≥Vol ≥ EVol (100 Mb) ≥EVol (2 Mb)≥ free (3 Mb) ≥ ƒ¡ƒƒƒƒ¡ƒƒƒƒ¡ƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒ¡ƒƒƒƒƒƒƒƒƒƒƒ¡ƒƒƒƒƒƒƒƒƒƒƒƒƒŸ C) The user does a small backup which overwrites a portion of the previous volume, resulting in the remainder of the volume to be marked as a Bad Volume (BVOL). The tape now has 100 Mb free. ƒ¬ƒƒƒƒ¬ƒƒƒƒ¬ƒƒƒƒƒƒƒƒƒƒ¬ƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒ¬ƒƒƒƒƒƒƒƒƒƒƒ¬ƒƒƒƒƒƒƒƒƒƒƒƒƒø ≥ ≥ ≥ ≥ ≥ ≥ ≥ ≥Vol ≥Vol ≥Vol (5 Mb)≥ BVol (95 Mb) ≥EVol (2 Mb)≥ free (3 Mb) ≥ ƒ¡ƒƒƒƒ¡ƒƒƒƒ¡ƒƒƒƒƒƒƒƒƒƒ¡ƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒƒ¡ƒƒƒƒƒƒƒƒƒƒƒ¡ƒƒƒƒƒƒƒƒƒƒƒƒƒŸ D) The user inserts the tape and attempts a Read/Write test. The Read/Write test uses the following alorithm to decide where to write the test data: 1) Check for unused space at the end of the tape. If this fails, continue to step 2. 2) Look at the previous volume, if it is an EVOL, continue with step 3, otherwise goto step 5. 3) If there is > 5700 Kbytes from the beginning of this EVOL to the end of the tape, go to step 4, otherwise, repeat step 2. 4) Success! Start writing the Read/Write test data here. 5) Failure! The tape is full. The decision was made not to attempt to overwrite Bad Volumes due to the fact that they are not maintained in natural (sequential) order in the Volume Table at the start of the tape. Volume table entries for Bad Volumes are always placed at the end of the table. To solve the problem the volume table entries would have to be sorted by start-segment and then processed. Due to time constraints, the previously described algorithm was implemented. Customer Support technicians should be aware of this so that they can respond if this scenario occurs. XX. On-line help text is now read directly from the language text file tape.txt on a demand basis. As a result of the changes to the on-line help system, an additional file ("TAPE.NDX") must be present in the install directory to run the software. TAPE.NDX is the help index file and it is created by INSTALL.EXE when the software is installed. If this file is inadvertently deleted, modified or otherwise compromised, it can be recovered by re-installing the software. 3. The installation utility "INSTALL.EXE" has been modified to support a single disk implementation of CBD and CBW Lite. The changes consist of xx. USING QEMM's VIDRAM UTILITY: The use of the Quarterdeck utility VIDRAM.COM that is shipped with QEMM is not supported by the tape/diagnostics software. VIDRAM allows graphics RAM to be configured as conventional memory by the memory manager. On some systems, the only side effect is that the screen colors will be "mangled". However, some systems may hang or report a memory allocation error and abort. xx. We now complete certification without any failures, but with a couple of notes, such as Mac directory restrictions and comments. Certification issues fixed for 4.04 ------------------------------------ 1) Wide and deep directories are functional at Novell's specs. Note: This change should also fix the error 30000 about allocating too many directory handles on the server (what I said earlier). 2) Odd character names 3) Volume restrictions for 3.x 4) System bit on directories for 2.2 (NOTE: the private bit on directories will not (cannot) be backed up.) There has been an error 30000 on allocating directory handles on the server (something to that effect) that should be fixed with the new algorithm for searching the disk. 
